(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ordlogo.gif)
Designer/2000
Introduction
Designer/2000
Introduction
By David C. Moss
In our last article on Designer/2000, we explained how Function Hierarchy modeling helps you and your users reach agreement on the scope of your application-what's in and what's out. With this agreement, it's easier to determine how proposed changes will impact your application after you've begun coding.
Function Hierarchy modeling is an important step in creating a complete logical model of your business--the most effective way to determine the areas that would benefit most from automation. To round out our logical model, we'll now consider how to determine the information your organization needs to support the Business Process and Function Hierarchy models.
In this article, we'll discuss how you can use Entity-Relationship (E-R) modeling to create a logical data model of your organization's information needs. The logical data model you create using Designer/2000 will later become the basis for creating tables, columns, and foreign keys and will ultimately generate Data Definition Language (DDL) scripts to be used in creating your database.
Before creating this important model, we'll first discuss some rules and conventions used in E-R modeling. Then we'll look at what you need to do to gather the information necessary to create and alter your model.
Like other models, an E-R model is a picture you can use to help reach agreement and understanding with your users. In this case, we're interested in defining the information needs for your organization or application. So, why should we create a logical model of these needs? Why don't we just create some Oracle tables and start coding?
The answer is: You need a model of your organization's information that's independent of the way it will later be stored and accessed. Creating tables now, without an information model, means you completely approve of the way things are currently being done. But what if you think things could be done just a little bit better? Then you need an information model.
An information model allows you to approach your organization from a fresh perspective and show how information should be used, not how it's currently used. This process can also help you to examine and choose the most efficient means of storing and accessing that information, in a way that wouldn't be possible without a solid information model.
Organizing information into a model is most successfully done using E-R modeling. An E-R model shows each item of significance in your organization or application and how it relates to another piece of information. The main components of an E-R model are entities, depicted as rounded boxes, and relationships, depicted as solid or broken lines between two entities.
An entity is a thing or object of significance, real or imagined, about which you need to know or hold information. Things of significance to Frick & Frack Financial would be customers, accounts, and employees. Other examples include orders, departments, loan programs, contracts, and products. In other words, an entity represents a piece of information that people work with on the job. On a small project, an E-R model may have 15 to 20 entities. On a large project, the number can easily reach 200.
It isn't enough to simply list all of the entities your organization needs for an application. You also need to show how these entities in your organization relate to each other, such as whether a customer can have one or more accounts. In E-R modeling, a relationship defines how two entities interact. Using the E-R Diagrammer in Designer/2000, you describe the business relationships between two entities in plain English.
In an E-R model, you read two entities at a time and describe the relationships in each direction. Reading the relationships between the two entities Customer and Account in Figure A, we obtain the following relationship sentence:
A relationship between entities can be mandatory or optional. You depict must be by a solid line attached to the entity; you depict may be by a dotted line attached to the entity. This is known as the optionality of the relationship. Relationships refer either to one and only one occurrence of an entity, depicted with a solid line, or one or more occurrences of an entity, depicted with a crow's foot. This is known as the cardinality or degree of the relationship. Finally, you need to describe the business relationship between the entities, for example, that a Customer is the holder of one or more Accounts.
Now that you know the basic rules for reading an E-R model, let's look at Figure A for some more examples. In addition to the relationship between the Customer and Account entities, which we've already read, the diagram reads:
Now that you know how to read an E-R model, you need to determine which entities should appear in your E-R model. This requires some detective workóasking the right questions of the appropriate people in such a way that youíll get the answers you need to create an agreed-upon model.
As we discussed in our article on Function Hierarchy modeling in the March 1996 issue, Oracle's CASE*Method suggests two complementary modeling approaches: top-down and bottom-up. Using directional interviews, where the highest-level executives affected by your application set the direction of the project, and in-depth interviews, where specific business areas that have been designated from the directional interviews can be explored in more detail, you can obtain most of the entities you need to begin modeling.
As in Function Hierarchy modeling, it's very important to obtain and document agreement on the definition of each entity, especially if you work in an organization that uses the same word, such as account, to describe many different things. Being specific about entity definitions now will prevent confusion later.
Please note that, in both directional and in-depth interviews, you'll be asking questions to determine entities, functions, and any other information you need to create a complete logical model. Although we've discussed E-R, Function Hierarchy, and Process modeling in separate articles, in the real world the collection and modeling of this information is usually accomplished simultaneously.
Once you've collected and identified a number of entities, you need to determine their relationships and create a coherent model so that the parties can reach agreement and the application can move forward. In creating an E-R model--as opposed to a Function Hierarchy model--layout plays a considerable role. That's why the E-R Diagrammer in Designer/2000 allows you considerable flexibility on size and location of the entities on your diagram. Please note the different sizes and locations of the entities in Figure A.
The E-R Diagrammer is a powerful tool, with very specific modeling rules. While this sometimes means more work in creating a high-quality model, it also frees you to focus on the needs of your organization instead of inventing your own approach. As we've discussed in previous articles, keeping the communication lines open with your users by continually reviewing the E-R model as it develops is vital to the successful completion of your organization's logical model. We'll discuss the final component in creating your logical model, matrix diagramming, in the May issue.
The E-R model shows the informational scope of your application--the information that will eventually become the working data model that all programs in your application will draw data from. Entities will typically become tables and relationships will become foreign keys. As in the Function Hierarchy model, if an entity doesn't appear in your E-R diagram, your application won't implement it.
Please remember that a good E-R model should allow for changes in your organization over time. You can't predict where all of those changes will be, yet it's surprisingly easy to see where your organization is most in flux. For example, at our fictitious firm Frick & Frack Financial, the management structure has always been the same, but loan programs and interest rates change almost daily. Knowing the unique characteristics of your organization, you can create an E-R model that will provide a stable structure for the organizational chart, yet allow a flexible structure for new loan programs and interest rates.
Once you've created a model in the Entity-Relationship Diagrammer, how do you know when you're finished? Depending on which stage of the project you're in, you'll need to ask the following questions:
You'll also need to cross-check the E-R model with the Function Hierarchy and Process models for completeness. This cross-checking process is known as matrix diagramming.
The remaining tool in Designer/2000 for modeling the logical part of your application is the Matrix Diagrammer, which we'll examine in detail next month. We'll then be ready to begin our discussion of the physical aspects of application development using the Database Design Wizard and the Applications Design Wizard in Designer/2000. After that, we'll begin examining various components and techniques of Designer/2000 in greater detail.
If you'd like to find out more about Oracle's approach to Entity-Relationship Modeling, please read CASE*Method - Entity Relationship Modelling by Richard Barker (Oracle/Addison-Wesley, 1990). The rules and conventions discussed in the book are the ones implemented in Designer/2000. We recommend the book as a reference--even for experienced E-R modelers.
David Moss is a managing consultant with TrueNorth Consulting, Inc., an information management consultancy with offices in Portland, Oregon, and Bellevue, Washington. You can reach him by phone at (503) 220-1790 or by E-mail at truenrth@ix.netcom.com.
[Return to Index for Exploring Oracle Developer/2000 and Designer/2000 - April 1996]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis
Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of
Ziff-Davis Publishing Company.
1-800-223-8720
(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ord9604/eod9644a.gif){kind=link}